Internet Warrior 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ Internet Warrior 1993 July / Internet Warrior No. 1 July 1993 - Austin Code Works.ISO / tcpip / cuttcp / setup.txt < prev next >

Wrap

Text File | 1992-12-27 | 19.5 KB | 592 lines

May 22, 1987 page 1 To: All TCP/IP system programmers From: Eric Norman About: Generic Network Setup. _1. _I_n_t_r_o_d_u_c_t_i_o_n. This note is addressed to all system programmers who are installing or maintaining network software using the TCP/IP suite of protocols. I will attempt to mention things that you should know before connecting your host to the campus network. Since this is supposed to be useful for all, I cannot give precise details about setting up a net- work connection; however, details will often be given for common operating systems (notably Unix and its derivatives and WIN/VX from The Wollongong Group). Since the campus network is a resource that is shared by all departments on campus; I will also point out some things that you should be careful about so that you do not interfere with other users of the network. _2. _H_o_s_t _i_d_e_n_t_i_f_i_c_a_t_i_o_n. We expect that all hosts attached to the campus network be registered so that we know where they are, what software they are running, and whom to contact in case of trouble. They should be registered with the network administrator at MACC. Currently that's me (Eric Norman; 262-3854; 3153 MACC). It would be easiest for me if this information were provided in the following form: Domain: macc.wisc.edu Name: vms Aliases: bossie wircs1 wiscmacc vms Interfaces: 128.104.30.10 Services: (TCP) Telnet FTP SMTP Finger - (UDP) Who CPU: VAX-11/785 OS: VMS (with Eunice) Location: MACC; 1210 West Dayton Street Contact: Eric Norman; 262-3854 - <ejnorman@unix.macc.wisc.edu> _2._1. _O_f_f_i_c_i_a_l _h_o_s_t _n_a_m_e_s. The name space of the Internet community is structured along what are designed to be administrative boundaries. The local convention is that official host names look like: May 22, 1987 page 2 "host.dept.wisc.edu". The "wisc.edu" part is dictated by the fact that we are an educational institution (edu) and that we are the one in Wisconsin (wisc.edu). The next sub- division is according to department (dept.wisc.edu would be the domain above), and finally individual hosts within that department. For instance, "larry.sal.wisc.edu" is a host in the Space-Astronomy laboratory, "bert.chem.wisc.edu", is a host in the Chemistry department, and so forth. _2._2. _N_i_c_k_n_a_m_e_s. For local convenience, hosts generally have a set of nicknames that they are known by. Note that this is only local; such nicknames will not be known in the external world (i.e. outside of the University of Wisconsin), where the long, official name should be used. Most people adopt at least the first part of their official name as a nickname (e.g. "daryl.sal.wisc.edu" has a nickname "daryl"). Other nicknames might be used if the host is known by different names on different networks. "Daryl" above also has DECnet connections, where he is known as "uwsal", so he also has that as a nickname. Most organizations choose a theme for their nicknames, Computer Sciences names their Microvaxes after cheeses, Milwaukee uses beers, MACC and a few other places around campus use cows, etc. This is not just "cute", it also serves the purpose of eliminating conflicts somewhat. If conflicts do arise, they will be resolved on a first come, first served basis. _2._3. _I_n_t_e_r_n_e_t _a_d_d_r_e_s_s_e_s. Associated with each host is an Internet address. This is the actual "name" for the host as far as other computers are concerned; they are unique throught the world. These addresses are written as four numbers separated by dots, e.g. 128.104.39.10; each number can be anything from 1 to 254, inclusive. This number is the "interface" field above. I will assign a number at the same time that you register the official name and nicknames. In general, they will all start with 128.104 since that is the number that has been assigned to the campus network. If you are a large department and expect to install a local ethernet with many hosts attached, you will probably be assigned a block of Internet addresses, e.g. 128.104.38.1 through 128.104.38.254 (0 and 255 have special meanings). The third number (38 above) will be a "building number". Do not assume that it is the building number obtained from a current parking map; These change every year and you would not be happy if you had to change your Internet address after people are used to using it. May 22, 1987 page 3 _3. _C_o_n_f_i_g_u_r_a_t_i_o_n. There are configuration parameters that will have to be set before a host is connected to the network. _3._1. _I_n_t_e_r_f_a_c_e_s. In order to connect a host to the network, you will have to tell it what its Internet address is and possibly some other properties of the network being connected to. On Unix systems, this is done with a command in /etc/rc.local that should look like: ifconfig qe0 128.104.30.10 -trailers The command will look the same on Wollongong systems except that it appears in [NETDIST.MISC]STARTINET.COM. The "qe0" above may vary depending on the type of hardware you have; your installation instructions should clarify this. Other operating systems or TCP/IP software may differ, but there will generally be a configuration parameter called "internet address", or "interface address", or "IP number", or some- thing like that. On many systems, it is possible to use a symbolic name instead of the actual number. I have found that this is generally unwise. If something happens to the file (e.g. /etc/hosts) that is used to establish the correspondence between this name and the internet address, the machine will not boot correctly. Note that this includes the use of backquoted `hostname` in the configuration files distributed by Berkeley and Ultrix. If you do use a symbolic name, be sure that the name-number association is under your control and not something that you rely on someone else providing. _3._2. _T_r_a_i_l_e_r _e_n_c_a_p_s_u_l_a_t_i_o_n. If there is any mention of "trailer encapsulation" in your TCP/IP configuration, please make sure it is disabled (that's the "-trailers" above); there are many hosts on the network that cannot understand this feature. If this is not mentioned, then you don't have it, so don't worry about it. This is an "enhancement" that was done at Berkeley and is really only useful on networks where everyone runs Unix. _3._3. _S_u_b_n_e_t_s. If you have subnetting support, we don't use it here. You can either use the default or specify a netmask of FFFF0000 (hex). This usually won't be a concern unless your host used to be on a network where subnetting was used. This may change in the future if enough hosts have subnet- ting support. May 22, 1987 page 4 _3._4. _B_r_o_a_d_c_a_s_t _a_d_d_r_e_s_s. If you have the option of specifying all zeros or all ones for the broadcast address, this should be set to all zeroes. E.g, in BSD4.3 Unix and Ultrix, the "ifconfig" com- mand should contain "broadcast 128.104.0.0" as an option. The standard broadcast address is all ones, but there are still many hosts that are based on BSD4.2 Unix, so we have to stick with that until everyone can change. Many newer releases of TCP/IP come with the "all ones" as a default since it is the standard. If that is the case, be sure to change it back to all zeroes. One of the things provided with Unix systems that uses broadcasts is the "rwho daemon". For the time being there is no objection to running it; however, in the future we all may have to disable them if they cause too much network traffic. If you have BSD4.3, I would like you to check with me before starting the rwho daemon. The one that comes from Berkeley is often not suitable. _3._5. _L_o_o_p_b_a_c_k _i_n_t_e_r_f_a_c_e. All software comes with a "loopback" interface. The conventional number for this is 127.0.0.1. On most systems this is supplied automatically and you needn't worry about it. BSD4.3 and newer Ultrices allow you to configure it just like any other interface; such systems will need a ifconfig lo0 127.0.0.1 (trailers are OK here since you're only talking to your- self). The first few tests you perform on your host should be using this interface (e.g. telnet 127.0.0.1). This will verify that the networking code is operational before send- ing packets out all over the campus. _3._6. _T_e_s_t_i_n_g. For purposes of testing your configuration, the above should be enough. It will allow you to communicate with any host on the local network (any host with a 128.104 number). It would be best to disable as many unnecessary things as possible for the initial test (e.g. rwhod, routed, send- mail, etc). If you are unsure of youself, you can get in touch with me when you do this. I have tools that I can use to "snoop" around on the network and see if machines are misbehaving or not. May 22, 1987 page 5 Many departments have given me guest accounts on their hosts so that I can look over things. _3._7. _R_o_u_t_i_n_g. In order to communicate with the rest of the Internet world (i.e. the ARPAnet and the NSFnet) you will need to tell your host where a gateway is. The gateway here is named "unix2.macc.wisc.edu" and also known as "Steer" or "Wilt"; its Internet address is 128.104.30.1. If you are on the USAN network (net 128.116 in Meteorology and Space Sci- ences for now), then the gateway's address is 128.116.12.1 NCAR will tell you to use 128.116.64.1; don't believe them. This gateway can be used if you never talk to anyone but NCAR. The USAN folks should also keep it in mind for use if our gateway goes down; they can reconfigure using 128.116.64.1 and still be able to at least talk to NCAR. If your host is on some other network (e.g. 192.12.224), then there's a gateway between you and Steer. Find out which it is and what its address on your network is. That's where your default route would go. It may not be possible for such networks to reach the external world for now; there is a limit to the number of networks on both the ARPA- and NSF- networks and we wouldn't be too welcome if we used more than "our share". There are two different ways to tell your host about the gateway. (1) You can specify a "default" route. On Unix-like systems, this would be done with a command in the startup file that looks like: route add default 128.104.30.1 1 (the "1" on the end is important). On other systems, there will probably be mention of a "default gateway" or something like that in the configuration. 128.104.30.1 is the number to use (128.116.12.1 for the USAN folks). What you are tel- ling your host is to relay all communication with hosts hav- ing an Internet address other that 128.104-something through the gateway. The gateway runs special software that learns about all the other networks on the Internet and how to get to them. (2) If you do have a "routing daemon" (/etc/routed on Unix systems) you can run it instead; it will learn about the default route and take care of it for you. This is the preferred method since it will also take care of the day when we have alternate gateways to the external world and automatically switch to a backup if one goes down. If you May 22, 1987 page 6 do have a Unix-like system with the routing daemon, you should use the "-q" option; this tells it to only listen to routing information and not supply it (most hosts have noth- ing interesting to say about their routes; only gateways have interesting things to say). _D_o _n_o_t use the "-g" or anything that would cause your host to announce a default route; if you do, you will be getting a nasty call from us. Do not use this even if you are a gateway. _4. _M_a_i_l_i_n_g _l_i_s_t_s. A mail reflector (mailing list) has been established on the gateway. It is intended to be used for messages of interest to the systems programmers that are actually main- taining the TCP/IP software of sundry hosts. This mail reflector is "netfolks@unix2.macc.wisc.edu"; mail to it will be sent to all the systems programmers. When you get your system up and running, you could send a message here to "introduce yourself". Questions about availability of net- work software, announcements of major changes (such as a gateway being down for an extended period), etc. are appropriate. Inquiries about statistical software or the like belong on some other mailing list that hasn't been created yet (suggestions and volunteers are welcome). There are also subreflectors "netfolks-unix" and "netfolks-vms" (both at Steer) for messages peculiar to those operating systems. When you get your mail system up and running, let me know who to add to this list. Most people establish an alias (netadm is common) so that this list doesn't have to be changed if someone else takes over the network hacking duties on a host. Mail to "netadm@unix2.macc.wisc.edu" will get to me. _5. _N_a_m_e_s_e_r_v_e_r_s. There is a nameserver running on Steer that serves all the subdomains (departments) of wisc.edu. There is also a "nickname domain" that contains all the nicknames. If you are using nameserver software and expect to communicate with campus hosts outside your department, the nickname domain would probably be the best one to use as your "default" domain. This domain is "nn.wisc.edu"; e.g. in Unix systems running BIND, you would put "domain nn.wisc.edu" in /etc/resolv.conf. If you don't know what I'm talking about here, you needn't worry about it; the nameserver business is new and still somewhat experimental. One problem you may notice because of this is that some of your users may not be able to mail to certain hosts. This is often because such hosts are known to the domain May 22, 1987 page 7 system (the nameservers) but not in the host tables. If you suspect that this is the case, relaying the mail through the gateway might be worth a try. I.e. you could try sending mail to user%funny_host@steer - or - <@steer:user@funny_host> _6. _P_h_y_s_i_c_a_l _N_e_t_w_o_r_k _C_o_n_n_e_c_t_i_o_n. MACC operates the campus-wide Ethernet based on our broadband cable system. See MACC document #1937, "UW- Madison Networks" for specifics and applications details. All equipment directly attached to the broadband Ethernet (i.e. Chipcom transceivers and LAN-100's) must be maintained by MACC. If you suspect hardware problems with this equipment, call the MACC Communication Facility, 263-4829, or Mike Dorl, 262-0466. It would probably be best to get in touch with Mike or me first so that we can verify that it looks like a hardware problem from "our side" too. _7. _R_e_a_d_i_n_g _m_a_t_e_r_i_a_l. In addition to the documentation provided with your system, MACC has some general user level documentation. The title is "Wisconsin IP Network User Manual", MACC #1103 and is available from the documentation desk in the lobby. _8. _M_i_s_c_e_l_l_a_n_e_y. _8._1. _H_o_s_t _t_a_b_l_e_s. Host tables are available via anonymous FTP from the gateway. Login as user "anonymous"; password can be any- thing; most use "guest". After logging in, change to the directory "etc". the file "hosts" is in Unix (Wollongong, Ultrix) format. It contains all the local hosts and nick- names at the front followed by the rest of the hosts avail- able from NIC. The files "depthosts" and "localhosts" are subsets of this. The file "localhosts.txt" contains Wisconsin hosts and nicknames in NIC format (IBM, CMU TCP/IP, Apollo, etc), the file "hosts.txt" is a fairly recent copy of the tables dis- tributed by NIC. For NIC format hosts, "localhosts.txt" concatenated with "hosts.txt" is usually what you want. May 22, 1987 page 8 _8._2. _S_e_c_u_r_i_t_y. If you are used to running a very relaxed system and not using passwords, I would advise you to institute them. There seem to be people around the world who will try con- necting to random hosts. If they get logged on to your machine, they just might try to demonstrate how "cute" they can be. Another hint: if a password is the same as the login name, it's effectively not a password. That's the first thing I would guess and the first thing a lot of other people would guess too. _8._3. _B_o_o_t _s_e_r_v_e_r_s _a_n_d _t_h_e _l_i_k_e. Some diskless workstations and other hardware expect a "boot server" to be available on the network. Do not install such a server on 128.104 unless you check with us. People will be quite unhappy if your boot server bootstraps their workstation. _8._4. _A_R_P Some older systems (e.g. Sun and old 4.2BSD's) do not use ARP for certain host numbers (less than 1024 usually). This causes no probelms on a class C network (192 numbers) but won't work on our class B network (128.104). If this is the case, you'll need to get a fix from the vendor. If you have a Unix system and can recompile the kernel, sys/netinet/if_ether.c is the place to look. There's a "#define" in there (I just changed it to 666666 when I had to do this, there's no particular reason for that number other than it's larger that 65536). _8._5. _D_E_C_n_e_t If your host also has a DECnet connection. Remember that TCP/IP cannot be started until DECnet is running. This is because DECnet needs to start first to initialize the hardware interface for it's own purposes. TCP/IP can use what DECnet sets up. Be sure that the instructions you have say that is is indeed possible to share the Ethernet with DECnet. With some systems (e.g. Wollongong), extra options are necessary to do this. _8._6. _M_a_i_l The official BITnet gateway is WISCVM.WISC.EDU. If you want to send mail to a BITnet user but do not have a BITnet connection, mail addressed to either user%node.bitnet@wiscvm.wisc.edu - or - <@wiscvm.wisc.edu:user@node.bitnet> May 22, 1987 page 9 should get there. Some hosts cannot handle the latter form of address properly. Similarly, our VMS critters can be used to relay local DECnet mail, e.g. user%node.decnet@bossie - or - <@elsie:user@node.decnet> Some Unix-like systems (Ultrix in particular) have con- figuration files for sendmail that just plain don't work. I can give you one that does.